30.4 KB · ⇊ 9 parts · ⤓ Micron 30.4 KB · ⤓ HTML 53.6 KB

top

In mwawtelecomunicazioni e mwbainformatica mwbqIPsec, abbreviazione di mwbgIP Security, è uno mwbwstandard per mwcareti a mwcqpacchetto che si prefigge di ottenere mwcgconnessioni sicure su mwcwreti mwdaIP. Tale mwdqsicurezza viene raggiunta attraverso l'aggiunta di funzionalità di mwdgautenticazione, mwdwcifratura e controllo di mweaintegrità dei mweqpacchetti IP (mwegdatagrammi). La capacità di fornire protezione o sicurezza viene dunque fornita a mwewlivello di rete (diversamente da mwfaHTTPS, mwfqSSL/TLS), fatto che rende questo mwfgprotocollo trasparente al mwfwlivello delle applicazioni che quindi non devono essere modificate.

• Panoramica dello standard

• Scopo del progetto

• Introduzione

• Dettagli tecnici

• Protocolli di IPsec

• IKE

• Authentication Header (AH)

• Encapsulating Security Payload (ESP)

• NAT traversal

• Elenco degli RFC relativi ad IPsec

• Voci correlate

• Altri progetti

• Collegamenti esterni

IPsec è stato progettato per rendere sicure sia comunicazioni mwhaportal-to-portal sia comunicazioni mwhqend-to-end. Nella prima configurazione il traffico viene reso "mwhgsicuro" a diversi computer (in alcuni casi ad un'intera mwhwLAN); nella seconda solo i mwiapeer che stabiliscono la connessione scambiano pacchetti protetti. Tuttavia l'uso predominante di IPsec è la creazione di mwiqreti private virtuali; per conseguire tale scopo possono essere utilizzati entrambi i metodi prima esposti.

IPsec è una collezione di mwjaprotocolli formata da:

• Protocolli che implementano lo scambio delle chiavi per realizzare il flusso crittografato.

• Protocolli che forniscono autenticazione, integrità e riservatezza del flusso di dati.

Esiste un solo protocollo per lo scambio delle chiavi, il protocollo mwkqmwkgIKE. IPsec è parte integrante di mwkwIPv6, mentre è opzionale in mwlaIPv4. Di conseguenza, ci si aspetta che sarà maggiormente utilizzato quando IPv6 acquisterà popolarità. Il protocollo è definito negli mwlqRFC 2401-2412. Dal mwlg2004 sono in corso studi per l'aggiornamento dei protocolli.

Per quanto riguarda il secondo aspetto, esistono due protocolli: Authentication Header (AH) e Encapsulating Security Payload (ESP).

mwmwAH fornisce autenticazione e mwnaintegrità del messaggio, ma non offre la riservatezza ed è il protocollo IP 51.

mwngESP fornisce invece autenticazione, riservatezza e controllo di mwnwintegrità del messaggio ed è il protocollo IP 50. Per questi motivi ESP è molto più usato di AH.

IPsec supporta due modalità di funzionamento:

• mwpaTransport mode

1. connessione mwpwhost-to-host;

2. usato dagli end-point, non dai mwqqgateway;

3. in caso di cifratura, viene cifrato solo il mwqwpayload dei datagrammi IP, non l'mwraheader;

4. computazionalmente leggero;

5. ogni host che vuole comunicare deve avere tutto il software necessario ad implementare IPsec;

6. si aggiunge solo l'header IPsec; gli indirizzi mittente e destinatario degli end-point sono rilevabili.

• mwsqTunnel mode

1. connessione gateway-to-gateway;

2. in caso di cifratura, viene cifrato tutto il pacchetto IP originale;

3. utilizzato per realizzare le VPN;

4. computazionalmente oneroso;

5. solo i gateway devono avere il software IPsec;

6. si hanno punti di centralizzazione, quindi single point of failure;

7. utilizza un doppio mwugincapsulamento, ponendo come payload della comunicazione tra indirizzi gateway quanto si ottiene cifrando l'unione di indirizzi mittente e destinatario degli end-point col payload effettivo; adottando il protocollo Encapsulating Security Payload, gli indirizzi mittente e destinatario degli end-point non sono quindi più rilevabili (restano invece rilevabili adottando AH).

Le due modalità sono supportate sia da AH che da ESP.

IPsec può essere utilizzato anche per connessioni tra gateway e host.

Il concetto di mwvwSecurity Association (in breve mwwaSA) è alla base del funzionamento di IPsec. Una SA è un "contratto" fra le due entità coinvolte nella comunicazione; in essa vengono stabiliti i meccanismi di protezione e le chiavi da utilizzare durante il successivo trasferimento dei dati. Nell'ambito di IPsec, stabilire le security association è compito del protocollo mwwqIKE, sebbene sia possibile anche impostarle manualmente; la procedura manuale è sconsigliata in quanto può introdurre errori che indeboliscono il tunnel.

Una peculiarità delle SA è che individuano una comunicazione unidirezionale; quindi durante la creazione della connessione le entità coinvolte creano e gestiscono una SA per ognuno dei versi della comunicazione, quindi 2 SA individuano un canale mwwwfull-duplex. Al fine di semplificare la gestione delle SA, viene utilizzato un apposito mwxadatabase detto mwxqSAD (mwxgSecurity mwxwAssociation mwyaDatabase), dove viene tenuta traccia delle SA attive. In particolare una SA è costituita dai seguenti parametri:

• Gli mwywindirizzi IP dei mwzapeer coinvolti nella comunicazione;

• Il protocollo che verrà utilizzato per il tunnel (AH o ESP);

• le tecniche di cifratura utilizzate e le relative chiavi;

• Un intero a 32 bit chiamato mwaaSPI, acronimo per mwaqSecurity mwagParameter mwawIndex.

Dall'esame dei parametri di una SA si deducono quindi tutte le informazioni necessarie per stabilire le modalità in cui il traffico debba essere protetto; il passo successivo è definire mwbqquale traffico debba essere protetto: di questo si occupa la mwbgSecurity Policy (in breve mwbwSP). Una SP è una regola che stabilisce che tipo di traffico deve essere instradato nel tunnel e quindi essere coperto da IPsec; in modo analogo alle SA, le SP sono contenute in un SPD (mwcaSecurity mwcqPolicy mwcgDatabase). La security policy contiene:

• Indirizzo sorgente e indirizzo destinazione del pacchetto. Tale informazione è già contenuta nella SA e quindi può sembrare ridondante. In realtà questa informazione ha senso quando viene utilizzato il Tunnel mode.

• Il protocollo e la relativa porta da instradare nel tunnel. Questa opzione dipende dall'implementazione del protocollo e non è sempre contemplata; nel caso non sia disponibile, tutto il traffico prodotto viene veicolato nel tunnel.

• Un identificativo della SA da utilizzare per processare i dati.

Una volta stabilita la mweasecurity association e la mweqsecurity policy, può cominciare la comunicazione che sfrutterà il protocollo AH o il protocollo ESP cui verrà passato il parametro SPI, che permetterà di risalire alle tecniche crittografiche da utilizzare per la trasmissione.

IKE è un mwfwacronimo per mwgaInternet mwgqkey mwggexchange ed è il protocollo usato per stabilire una mwgwsecurity association nella suite di protocolli mwhaIPsec. Questo protocollo è definito in mwhqRFC 4306. È un protocollo di mwhglivello applicazione e utilizza il protocollo mwhwUDP come mwiaprotocollo di trasporto; la mwiqporta su cui viene stabilita la mwigconnessione è 500.

L'obiettivo di IKE è stabilire uno mwjashared session secret, ossia una chiave condivisa corrispondente alla sessione da instaurare e a tal fine utilizza l'algoritmo di mwjqDiffie-Hellman; dallo mwjgshared secret vengono successivamente derivate le chiavi crittografiche che verranno utilizzate per la successiva comunicazione. Al fine di autenticare le entità coinvolte nella comunicazione possono essere utilizzate tecniche a chiave simmetrica o, alternativamente, a chiave asimmetrica; in quest'ultimo caso si fa ricorso a mwjwinfrastrutture a chiave pubblica (PKI) e all'uso di mwkacertificati digitali.

mwlaAuthentication Header (abbreviato mwlqAH), è un protocollo che fa parte della suite IPsec. Il suo compito è quello di fornire un controllo di integrità pacchetto per pacchetto, verifica dell'autenticità del mittente e protezione contro i mwlgreplay attack. AH non garantisce in alcun modo la confidenzialità del messaggio.

L'autenticità è garantita tramite funzioni di hash a chiave simmetrica, ossia tramite il meccanismo delle pre-shared keys. Per poter comunicare, due entità devono condividere la medesima chiave; tale chiave viene combinata con il messaggio originale e quindi viene calcolato il mwmachecksum tramite una funzione di hash crittografico(MD5 o SHA). Il messaggio e il checksum vengono, infine, inviati al mwmqpeer remoto. Il mwmgpeer remoto riceve il messaggio; dato che questo è in chiaro, lo può leggere, combinare con la chiave di cui è a conoscenza e calcolare il checksum. Se il checksum corrisponde a quello inviato, il messaggio è autentico e viene accettato altrimenti viene scartato in quanto è stato modificato in un modo non consentito dallo standard.

Il protocollo AH è progettato per proteggere l'intero pacchetto IP inviato; tuttavia bisogna considerare che alcuni campi dell'header IP, come il mwnaTTL, variano durante la trasmissione; queste modifiche devono essere necessariamente consentite, per cui prima di calcolare il checksum, i campi cui è permesso variare vengono posti a mwnq0.

Di seguito viene illustrata la struttura del pacchetto AH (ogni casella rappresenta 1 mwoabyte).

Indica che tipo di protocollo verrà dopo.

La lunghezza dell'AH in word (1 word = 32 bit) meno 2. Per esempio, 96 sono i bit di default del campo Authentication Data, più altri 96 bit per i campi di lunghezza fissa di AH fanno 6 word (96+96 = 192 bit, diviso per 32 = 6). Sottraendo 2 risulta quindi 4 il valore contenuto della dimensione del payload standard.

Spazio lasciato per sviluppi futuri. Tutti i bit di questo campo vengono impostati a 0.

Questo campo identifica i parametri di sicurezza in combinazione con l'indirizzo IP. In genere è un numero pseudo-casuale che identifica la security association cui fa parte questo pacchetto.

Una successione di numeri mwvwmonotonicamente crescenti. Per impedire i mwwareplay attack, il sequence number quando raggiunge il valore massimo (2^{32}-1) non deve ritornare a 0, ma una nuova SA deve essere creata.

Contiene l'Integrity Check Value (ICV) e rappresenta l'mwwwHMAC calcolato dal mittente del messaggio. L'HMAC viene calcolato utilizzando i campi dell'header IP (con il mwxaTTL originario), i campi dell'header AH tranne i dati dell'autenticazione (viene considerato a 0) e infine tutti i dati degli header di livello superiore, compresi quelli applicativi, che non vengono modificati durante il trasporto.

AH supporta nativamente sia il mwxwtransport mode che il mwyatunnel mode. In transport mode vengono protetti solo i protocolli di livello superiore a quello di rete (mwyqTCP, mwygUDP, etc); in tunnel mode il pacchetto IP originale viene incapsulato in un nuovo pacchetto IP, dopo essere stato elaborato da AH. Ne spieghiamo il funzionamento con l'ausilio di alcuni disegni. Il metro di confronto è senza dubbio il pacchetto IP originale; in presenza di un collegamento basato su IPsec il pacchetto viene, ovviamente, alterato.

mw0gPacchetto IP originale

A seconda della modalità di funzionamento di IPsec (tunnel mode o transport mode), il pacchetto originale viene alterato in modo diverso.

mw4aAH in transport mode

mw7gAH in tunnel mode

La linea azzurra indica le zone del pacchetto che sono autenticate. Dal punto di vista della protezione, in entrambi i casi, i pacchetti vengono protetti completamente. Notiamo che nell'header IP, alcuni campi variano durante il transito nella rete, ad esempio il mw8aTTL. Questi campi vengono posti a mw8q0 prima di calcolare la mw8gfunzione di hash, necessaria per la protezione del pacchetto. Da quanto appena detto si evince subito che il protocollo AH è incompatibile con le varie tecniche di mw8wNAT; difatti se vengono alterati i campi indirizzo nell'header IP (in entrambe le modalità), in ricezione la checksum fallisce subito.

mw9wEncapsulating Security Payload, denotato con l'mw-aacronimo mw-qESP, è un protocollo che fa parte della suite IPsec. Il suo obiettivo è fornire autenticità, confidenzialità e controllo di integrità alla comunicazione. Contrariamente a quanto fa AH, l'header IP non viene coperto dai controlli. Al pari di AH, però, supporta sia il tunnel mode che il transport mode.

Di seguito viene riportato il formato del pacchetto mw-qESP (ogni casella rappresenta 1 mw-gbyte).

Al pari di quanto avviene in AH, questo campo, in combinazione con l'indirizzo IP, individua la Security Association cui appartiene il pacchetto.

Una successione di numeri monotonicamente crescente, che identifica il pacchetto all'interno delle Security Association e previene da mwasureplay attack.

I dati che devono essere trasferiti

È un campo di riempimento. È necessario in quanto alcuni codici di cifratura lavorano su blocchi di lunghezza fissa. Serve a far crescere la dimensione dei dati fino a divenire multiplo del blocco che l'algoritmo in uso riesce a gestire.

Rappresenta, in ottetti, la dimensione dei dati di padding aggiunti.

Identifica il protocollo dei dati trasferiti

Contiene i dati usati per autenticare il pacchetto.

Come si può vedere dalla struttura del pacchetto (ma sarà illustrato meglio in seguito), ESP "mwateavvolge" i dati dei protocolli di livello superiore, contrariamente a quanto fa AH che antepone un header.

Essendo un protocollo per il trasferimento dati della suite IPsec, ESP supporta sia il Tunnel mode che il Transport mode. A seconda della modalità tratta i dati in modo differente. Prima di descrivere l'incapsulamento dei dati mostriamo il pacchetto IP originale, che transiterebbe sulla rete in assenza di IPsec

mwatsPacchetto IP originale

mwavyESP in Transport mode

mwaxiESP in Tunnel mode

Le linee verdi sottendono la parte di pacchetto che viene sottoposta a crittografia, mentre le linee azzurre sottendono la parte di pacchetto che viene sottoposta a controllo di autenticità e integrità. Nella modalità trasporto l'header IP originale rimane in chiaro (quindi non protetto) per l'instradamento del pacchetto fino all'endpoint destinatario che sarà anche responsabile di processare l'autenticazione e la decrittazione del payload ESP. Diversamente, nella modalità tunnel l'header IP originale viene crittografato (quindi protetto) assieme all'header TCP e ai dati, ed è quindi necessario introdurre un nuovo IP header (in giallo) con le informazioni necessarie per l'instradamento fino al dispositivo delegato ( mwaxqgateway / mwaxufirewall ) alla chiusura del tunnel IPsec con decrittazione del payload ESP, dispositivo che provvederà a sua volta ad inoltrare il pacchetto autenticato e decifrato verso l'endpoint dichiarato nell'header IP originale (in grigio). Per quanto riguarda gli algoritmi di cifratura possono essere utilizzati mwaxyData Encryption Standard (DES), mwaxc3DES, mwaxgAES e mwaxkBlowfish. Il controllo di integrità e autenticità viene eseguito tramite mwaxoHMAC (funzioni di hash); l'hash viene calcolato tramite una funzione di hash (mwaxsMD5 o mwaxwSHA1), utilizzando una chiave condivisa; l'hash ottenuto viene allegato al messaggio e inviato. In ricezione viene controllata l'integrità del messaggio. Come illustrato negli schemi, l'indirizzo IP più esterno non viene coperto dal controllo di integrità. Tale opzioni rende il protocollo ESP adatto ad essere utilizzato in alcuni tipi di mwax0NAT, in particolare in quelli statici. Tuttavia esistono soluzioni mwax4ad-hoc per il funzionamento congiunto di IPsec e NAT, come il NAT traversal.

mwayiNAT traversal (o più in breve NAT-T) è il nome di un protocollo facente parte della suite IPsec e standardizzato in diversi mwaymRFC, di cui quello ufficiale è mwayqRFC 3947. L'obiettivo di questo protocollo è fornire la possibilità di stabilire un tunnel IPsec anche quando uno dei due mwayupeer coinvolti subisce un'operazione di NAT per raggiungere l'altra entità coinvolta nella comunicazione.

Il mwaygNAT è una tecnica molto utilizzata per il riuso degli mwaykindirizzi IP. Tuttavia gli host dietro un mwayorouter (o un mwaysfirewall) che effettua operazioni di NAT non godono di connettività end-to-end. Sebbene esistano diversi tipi di NAT, l'obiettivo generale è l'alterazione degli header del pacchetto. Questo comportamento è in netto contrasto con IPsec che ha tra i suoi obiettivi il controllo dell'mway0integrità del pacchetto. In particolare il NAT è incompatibile con AH sia in tunnel mode che in transport mode, in quanto AH verifica l'integrità di tutto il pacchetto IP. ESP, invece, non copre l'header IP con controlli di sorta né in Tunnel mode né in Transport mode, per cui risulta adatto nel caso in cui il NAT eseguito sia di tipo SNAT; in altre parole, la modifica apportata dal router deve coinvolgere mway8solamente l'header IP e non anche la mwazaporta del livello superiore.

Il NAT crea problemi anche con IKE e soprattutto con IKE in mwazimain mode. Il main mode usato congiuntamente al metodo delle mwazmpreshared-keys richiede l'autenticazione degli host coinvolti nella comunicazione e tale autenticazione prevede un controllo sugli indirizzi IP; per cui l'alterazione dell'indirizzo da parte di un'apparecchiatura di NAT provoca il fallimento dell'autenticazione.

In genere, nei dispositivi preposti alla gestione dei tunnel IPsec e nei client VPN, il NAT-T non è abilitato di default ma deve essere impostato a mano; tuttavia il suo utilizzo rimane opzionale: difatti durante la creazione della mwazusecurity association, i peer determinano se uno dei due subisce operazioni di NAT e solo in questo caso viene usato il NAT-T; questa operazione viene fatta durante la prima fase della negoziazione mwazyIKE. In prima battuta, i mwazcpeer verificano che entrambi siano in grado di supportare in NAT-T; questa verifica è eseguita nella primissima fase del protocollo IKE, per mezzo di un pacchetto con un campo mwazgVendor-ID, che contiene un valore hash noto.

Una volta stabilito che entrambi supportano il NAT-T, vengono inviate delle frame "NAT-Discovery" (NAT-D), in modo da verificare chi dei due subisca il NAT, o al limite se lo subiscano entrambi.

Una volta stabilito chi subisce il NAT, la comunicazione si sposta su una nuova coppia di porte UDP e l'entità "mwazsnat-tata" comincia a inviare delle frame mwazwkeepalive; queste frame servono a mantenere fisse le porte di comunicazione sul router e ad impedirgli di riassegnarle ad una nuova comunicazione.

Descriviamo come viene incapsulato il pacchetto originale ESP.

mwaakESP in Tunnel mode

mwabcESP in Tunnel mode con incapsulamento UDP per NAT-T

I campi segnati in mwabkverde scuro sono quelli relativi al NAT-T; questi campi vengono inseriti subito dopo l'header IP esterno, che non viene alterato, così come non vengono alterati i campi successivi. In ricezione viene fatta l'operazione inversa.

• mwab0RFC 4301: Security Architecture for the Internet Protocol

• mwab8RFC 2402: Authentication Header

• mwaceRFC 2406: Encapsulating Security Payload

• mwacmRFC 2407: IPsec Domain of Interpretation for ISAKMP (IPsec DoI)

• mwacuRFC 2408: Internet Security Association and Key Management Protocol (ISAKMP)

• mwaccRFC 2409: Internet Key Exchange (IKE)

• mwackRFC 2410: The NULL Encryption Algorithm and Its Use With IPsec

• mwacsRFC 2411: IP Security Document Roadmap

• mwac0RFC 2412: The OAKLEY Key Determination Protocol

• mwac8RFC 3947: Negotiation of NAT-Traversal in the IKE

• mwadmSicurezza informatica

• mwaduHTTPS

• mwadcTransport Layer Security

• mwadkSecure Shell

• mwadsIP spoofing

Altri progetti

• Wikimedia Commons

• Wikimedia Commons contiene immagini o altri file su IPsec

• mwaeahttp://www.ipsec-howto.org/italian/x151.html

• mwaeiIPsec e TLS a confronto: funzioni, prestazioni ed estensioni, su linux.it.

• mwaeqHow to pass IPSec traffic through ISA Server, su isaserver.org. URL consultato il 4 luglio 2005 (archiviato dall'url originale il 3 maggio 2005).